8bitfiles.net/archives

home *** CD-ROM | disk | FTP | other *** search

/ 8bitfiles.net/archives / archives.tar / archives / compuserve-file-archive / 03 Demos and Info / XMODEM.TXT < prev next >

Wrap

Text File | 2019-04-13 | 25.5 KB | 793 lines

XMODEM and COMPUSERVE October, 1984 NOTE: XMODEM, like the rest of the CompuServe Information Service, is provided on an "as-is, as-available" basis. Questions and Answers --------------------- Question: Why doesn't XMODEM work with my PC-Talk program? Answer: PC-Talk works just fine with CompuServe's implementation of the XMODEM protocol, but you need to be running 8 bits / no parity in order for PC-Talk to do XMODEM. See: Section 4.2 Question: I download a file using XMODEM, but all I get are a bunch of hexidecimal characters (something like: :1800100AB759CDEF7) What I doing wrong? Answer: You need to specify that you are downloading a binary file, rather than a text file. You can do this by appending a "/type:bin" in the download command (for example: dow chess.bin/proto:XMODEM/type:bin ) or by selecting transfer type 2 (Binary) from the download menu. See: Section 3.2 Question: I download a file using XMODEM, but all I get is a very short file full of garbage. Answer: You may be trying to download an ASCII (text) file as if it were a binary file. Append "/type:ascii" to the filename in the download command (for example: dow chess.txt/proto:XMODEM/type:ascii or select transfer type 1 (ASCII) from the download menu. See: Section 3.2 Question: My Crosstalk program doesn't work with CompuServe's XMODEM! Answer: Crosstalk XVI 3.4 has some compatibility problems with CompuServe, and cannot be used as is. There - 1 - XMODEM on CompuServe October 1984 is a patch in the IBM PC Sig's XA5 database (called CISXTK.TXT) which can be used to make Crosstalk work well with CompuServe. Future versions of Crosstalk should work well with CompuServe. See: Section 4.1 Question: My <fill in the blank> terminal program doesn't work with CompuServe's XMODEM, but it works just fine with everybody else! What are you doing wrong???? Answer: The XMODEM protocol was never designed with the idea of communicating over a packet switching network to large time sharing computers. The biggest problem comes from the fact that the network introduces delays between the host and the micro and that the host may not be able to respond quickly to the micro's communications. Most terminal programs do work with CompuServe, and many that do not can be patched to work with CompuServe (e.g., Crosstalk) by simply relaxing the timing parameters in the program. See: Section 3.1 Question: Does your XMODEM implementation handle CRC checking as well as checksumming? Answer: Yes. See: Section 2 Question: Where can I find documentation on the XMODEM protocol? Answer: The closest thing to an official document specifying the XMODEM protocol is a small notes file Ward Christensen wrote describing the basic protocol. This file can be found in many of the SIGs on CompuServe. See: Reference [1]. - 2 - XMODEM on CompuServe October 1984 0. Abstract CompuServe has implemented a version of the XMODEM protocol that allows most XMODEM users to successfully transfer files securely between their micros and CompuServe's hosts. This implementation was not and cannot be 100% faithful to the original XMODEM specification (see reference [1]), and the differences between micro to micro XMODEM and micro to host XMODEM has caused some people problems. The purpose of this short article is to describe, in detail, the most frequent problems people have with micro to host XMODEM, and to offer some suggestions on how to overcome these problems. 1. XMODEM's origins The XMODEM (aka MODEM7) protocol was originally devised by Ward Christensen as a protocol for communicatons between microcomputers. As it was originally devised, the user runs a program called "MODEM", and dials up another computer. The user then instructs the remote computer to run a program called "XMODEM". XMODEM and MODEM then use the XMODEM protocol to transfer files between the two computers. The XMODEM protocol has several assumptions implicit in its design, and these assumptions are the source of the problems people have in using XMODEM protocol on CompuServe. Some of these assumptions are: o File lengths are exact multiples of 128 bytes. o Word size is 8 bits on both computers. o Data is transmitted 8 bits, no parity, one stop bit. o Both computers are dedicated (single user) microcomputers. o Both computers are talking to each other directly over a phone line. 2. The XMODEM protocol The XMODEM protocol is a half duplex protocol -- infomation travels in only one direction at once. The basic protocol works something like this: 1. When the receiver is ready to start receiving data, it transmits a <nak> (negative acknowledgment) - 3 - XMODEM on CompuServe October 1984 character to the sender, and continues to do so every 10 seconds until: 2. The sender sends a block. Each block contains the block number (modulo 256), 128 bytes of data, and a checksum. Once the block is sent, the sender waits while: 3. The receiver verifies that he received the block correctly; if the received checksum matches, then the receiver sends an <ack> character, and the sender sends the next 128 bytes of the file (step 2). If the block was not received correctly -- or if 10 seconds expires before a complete block is received, the receiver sends a <nak> character to the sender. When the sender receives a <nak>, it re-transmits the last block. 4. Steps 2 & 3 are repeated until the end of the file. At the end of the file, the sender sends an <eot> character instead of a block of data. 5. When the receiver sees the <eot>, it sends an <ack> to the sender, and then the file transmission process is complete. There is a variant of the XMODEM protocol that CompuServe also supports, called the CRC option. In the original XMODEM protocol, the checksum of each block was only one byte long. This small of a checksum (along with the algorithm used to generate it) allows errors to easily sneak into a supposedly error free protocol. The CRC option works roughly like this: Instead of the receiver sending out <nak>s at the very beginning, it sends out the letter "C". If the sender has the CRC option, it treats this just like a <nak>, but knows to compute the two-byte CCITT CRC-16 and add it to the end of all blocks instead of the one byte checksum. If the sender does not have the CRC option, then the "C" character has no meaning to it and is ignored. The receiver may try about three "C"s before deciding that the sender will not handle CRCs, and then the receiver transmits a <nak> to start a checksum-XMODEM file transfer. 3. XMODEM Problems on CompuServe - 4 - XMODEM on CompuServe October 1984 Because of the assumptions made in the XMODEM protocol, various difficulties arise in using XMODEM over CompuServe. Here are some major classes of problems: 3.1 XMODEM Timing Since XMODEM was originally devised for micro-to-micro communications, it has some problems fitting into an environment where one of the computers happens to be a mainframe and the two computers are not connected over a simple phone line but via a packet switching network. CompuServe's network can often introduce long delays in what should be continuous communications, as can a very busy host. When these delays arise, the microcomputer running XMODEM may mistake them for a breakdown in communications. If a long delay occurs in the middle of a packet -- in the middle of the data -- many XMODEM implementations see that as meaning there has been data lost. These delays result in the following symptoms: o The receiver cannot successfully receive even the first block of data. o The receiver consistently <nak>s blocks or <nak>s a majority of blocks, although eventually receives the file. o The receiver just suddenly gives up in the middle of a seemingly successful file transfer. o The receiver has great difficultly in receiving the file, and gives up anywhere from 5 to 20 blocks through the transfer. o The file transfer proceeds very smoothly with several successfully transfered blocks when all of a sudden every block transmitted is rejected (<nak>ed) by the host. Note that all of these problems are indistinguishable from other communications problems (e.g., noisy phone lines, bad parity settings). A key question to ask people who are having XMODEM problems is "Have you ever successfully done a XMODEM transfer to CompuServe?" If the answer is yes, then the following problems may be at fault. 3.1.1 Delays within blocks The XMODEM documentation [1] recomends that a gap of more - 5 - XMODEM on CompuServe October 1984 than 1 second be treated as a breakdown of communications. On a microcomputer, this makes sense -- there is no reason for a dedicated micro computer to suddenly stop transmitting and then resume. But on CompuServe's systems and network, a 1 second delay is not only possible, but happens frequently! If the microcomputer decides that this delay is a breakdown of some sort, it will send a <nak> to CompuServe, requesting that the block be retransmitted. Unfortunately, the rest of the first block is still "in the pipe" -- and when the receiver gets this block the receiver may do anything from abort the transfer to ignore it. Assuming the receiver handles the rest of the block gracefully (and the rest of the block doesn't look like the start of another block), the host will see the <nak> the receiver sent and retransmit the block. If there's a delay in the middle of that transmission, the receiver will <nak> it too, and so on forever. Thus, when the receiver is too sensitive to delays in the middle of transmissions, either the receiver gives up very quickly or the receiver <nak>s every block transmitted. 3.1.2 Delays between blocks Fortunately, most implementations of the XMODEM protocol aren't that sensitive to delays in the middle of blocks. But other delays can cause problems too. When a block is received by the microcomputer, for example, the micro will almost immediately <ack> or <nak> the block and wait for the next block to be sent. The XMODEM specification [1] states that if the next block does not arrive within 10 seconds, the receiver should send its <ack> or <nak> again. Ten seconds is not a very long time, however, when the network and/or mainframe is heavily loaded. Often, what will happen is that the <ack> or <nak> will arrive at the host, the host will begin transmission of the next block, but the block won't make it to the micro in time. Then, the micro transmits a <nak>, even though the host has correctly received the first <ack>/<nak>. What happens, then, is that a <nak> enters the network, even though the host has seen and responded to the first <ack> or <nak>. After that, things can easily degrade. The host may find itself one block ahead of the receiver, causing the receiver to give up on the spot. The host may - 6 - XMODEM on CompuServe October 1984 find itself stuck one <ack> or <nak> behind the receiver, which could result in a successful, although very difficult, file transfer. And the network problems could be severe enough -- or the micro sensitive enough -- that the micro goes through about 6 or so blocks (mostly <nak>s with a few <ack>s) and gives up. 3.1.3 Network Flow Control When the user is sending data to CompuServe, the node will send an XOFF (^S) character to the micro if the micro is transmitting faster than the node can send the data to the host. This happens even during an XMODEM transfer (although very infrequently). If the micro misinterprets the ^S as a <nak>, it will immediately retransmit the block -- causing the network to send even more ^Ses and the micro to see even more naks. Usually what happens is that the micro thinks that every block it transmits is being <nak>ed, and the micro gives up almost immediately. This problem can strike anytime during an upload to the host, and things can be proceeding very smoothly upto that point. 3.1.4 Timing suggestions and hints To overcome and avoid these problems, an XMODEM protocol implementation should wait 20 seconds before sending a <nak> on a lost block, wait at least 10 seconds during delays in the middle of a block, and honor (or at least ignore) flow control from the node during uploading of files. Many programs which have timing problems with CompuServe can be patched to relax their timing restrictions. A typical place to look is for calls to a "timed input" routine (where the routine will only wait so long for a character to arrive). Either patching that routine (make it wait twice as long, perhaps) or patching the code that calls the routine (to use a longer time out value) would help to make the XMODEM work on CompuServe. 3.2 Host file Format Concerns 3.2.1 The Host file format problems While almost all microcomputers have an 8 bit word (or multiple of 8 bits), CompuServe has a 36 bit word. Text files are stored with 7 bit bytes (5 of them per word). While this poses no problems for pure text files (as the ASCII character set is defined for only 7 bits of data), - 7 - XMODEM on CompuServe October 1984 "binary" files cannot be stored as is on our host systems (an example of binary data would be an executable program, or a WordStar file). Files in which 8 bits of data per byte must be preserved -- binary files -- are stored in a special file format (currently Intel hex format). Thus, when people upload or download to CompuServe using XMODEM, they are asked: Transfer types available, 1 - ASCII (7 - bit) 2 - Binary (8 - bit) Please make a selection: People often pick the wrong answer, the results are either an unsuccessful or useless upload or download. 3.2.2 The correct approach For uploading, the choice of a transfer type can be as simple as: "If it's a text file, use ASCII. If it's not, use binary." For downloading, the correct transfer type is the same one that was used to upload the file, i.e., if the file was uploaded with an ASCII transfer it must be downloaded with an ASCII transfer; if the file was uploaded with a binary transfer it must be downloaded with a binary transfer. At the moment, it is a problem for users to determine which type the file was uploaded in. Many SYSOPs have the file's description specify the correct approach for downloading. Other SYSOPs enforce the convention that files with a ".BIN" extension should be downloaded with the binary transfer while other files should use the ASCII transfer. It is best to ask what policy is in use if there is some doubt. In the future, the SIG program will be improved so that the choice of which transfer type won't be asked during a download. 3.2.3 What happens if... The user downloads a binary file with ASCII mode? The user gets the Intel hex format of the file. The - 8 - XMODEM on CompuServe October 1984 downloaded file can be salvaged by use of a program to convert Intel hex format back to binary. Currently, the IBM Novice forum (PCS-129) has such a program available. The user downloads an ASCII file in binary mode? The user usually receives one or two blocks of garbage data, at best. The user uploads a binary file in ASCII mode? The file transfer will not succeed, and any files left over after the upload will be useless. The user uploads an ASCII file in binary mode? The file transfer will succeed, but the uploaded file will be encoded into Intel hex format. Thus, any people who download the file in ASCII mode or use the Read command will receive a hex representation of the file. People who download the file in Binary mode, however, will be able to receive the file correctly. 4. XMODEM and .... 4.1 CROSSTALK (XTALK), version 3.4 Crosstalk has its timing parameters set too sensitively. Thus, it is virutually impossible to perform transfers using Crosstalk. MicroStuff, the creators of Crosstalk, have provided a patch to their software which allows it work with CompuServe. This patch can be found in the IBM PC SIG's database (see reference [2]). - 9 - XMODEM on CompuServe October 1984 4.2 PC-TALK III PC-Talk will work fine with CompuServe, so long as the user is running PC-Talk in 8 bits / no partiy mode. The most recent version(s) of PC-Talk are set up to switch to 8 bits / no parity automatically on an XMODEM transfer, but these versions are still rare in the user community. By default, CompuServe communicates in 7 bits, even parity. Thus, before PC-Talk can be thrown into 8 bits no partiy, the user must tell CompuServe to talk 8 bits no parity. The steps involved in making this change are as follows: 1. The user must log into CompuServe as usual (i.e., 7 bits even parity). 2. The user must then run the Default program. This program can be reached either by typing "R DEFALT" from command mode in the personal file area (the "OK" prompt), or by typing "GO DEFALT" from any "!" prompt. 3. In Default, the user should select option #5, "View or Change current terminal parameters." Then, he should select option #8, "Parity is", change parity to ZERO, and then exit the default program, making all changes permanent. 4. At this point, PC-Talk can be switched into 8 bits no parity. On some modems (but not most of the Hayes line of modems), doing this switch will cause the modem to hang up. Thus, it may be advisible to log off CompuServe before switching to 8 bits no parity. 5. Once PC-Talk is running in 8 bit mode, it is possible to easily upload and download using XMODEM. The next time the user dials into CompuServe (with PC Talk set to 8 bits no parity) and types control-c to catch the system's attention, the "User ID:" prompt will be garbled. Once the system recognizes the User ID, however, the - 10 - XMODEM on CompuServe October 1984 password prompt will be presented in clear text. Thus, users should just muddle through the garbled User ID prompt and everything will work well after that. If the user's modem does not hang up when the parity setting is changed, it is also possible to change to 8 bits no parity just before performing an XMODEM transfer, and change back to 7 bits even parity when it completes. This is a rather involved, manual process, though, and is not recomended. Note: Putting PC-Talk into 8 bits no parity is necessary even to upload or download ASCII files. - 11 - XMODEM on CompuServe October 1984 References ---------- [1] "Modem Protocol Overview" by Ward Christensen. Found various places throughout the system, including the Programmer's SIG's XA2 database in the file "PROTO1.DOC". This document is the starting point for anyone desiring to implement the XMODEM protocol, although the changes and suggestions presented here should be kept in mind. [2] Crosstalk XVI 3.4 patch. Found in the IBM SIG's XA5 database in the file CISXTK.TXT. This requires some sophistication on the part of the user, as it involves patching Crosstalk using the PC-DOS debug program. - 12 -